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REMARKS 

Reconsideration of this application as amended is respectfully requested. 

In the Office Action, claims 1, 3-29, 3 1-36 and 44-47 were pending and rejected. In this 
response, no claim has been canceled. Claim 25 has been amended. No new matter has been 
added. 

Claims 1, 3-15, 21-22, 24-29, 31-35, and 44-47 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over U.S. Patent No. 6,505,160 of Levy et al ("Lev/') in view of U.S. Patent 
No. 6,166,735 of Dom et al. ('TDom"). Claims 16-20, 23, and 36 are rejected under 35 U.S.C. 
103(a) as being unpatentable over Levy in view of Dom and U.S. Patent No, 6,097389 of Morris 
et al. ("Morris"). 

In view of the foregoing amendments, it is respectfully submitted that claims 1 , 3-29, 31- 
36 and 44-47 include limitations that are not disclosed or suggested by the cited references, 
individually or in combination. 

Specifically, for example, independent claim 1 recites: 

1 . A system comprising: 

a controller configured to select an identifier associated with a media object and 
to send a request to play the media object identified by the identifier, 
wherein the controller sends the request by wirelessly transmitting the 
request having the identifier stored in the controller over a first network, 
the first network being a wireless network : and 

an appliance configured to receive the request having the identifier from the 

controller over the wireless network, to determine whether the identified 
media object is stored in the appliance, to retrieve the media object from a 
first server via a second network different than the first network when the 
media object is not stored in the appliance, and to play the media object in 
response to the request . 

(Emphasis added) 

Independent claim 1 includes a controller that wireless conununicates with an appliance 
over a first network which is a wireless network, where the appliance communicates with a first 
server over a second network which is different than the first netwoik^ The controller sends a 
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request to the appliance to play a media object by wirelessly transmitting an identifier identifying 
the requested object in the appliance. In response to the request wireless received from the 
controller over the first network, the appliance determines whether the requested media object is 
locally stored in the appliance and retrieves the requested object from the first server over the 
second network (e.g., different than the first network) if the appliance does not have the 
requested object stored therein. Thereafter, the appUance plays within the appliance (rather than 
the controller) the retrieved object. It is respectfully submitted that the above limitations are 
absent from levy. 

Rather Levy is related to embedding an identifier within an audio stream, such that when 
the audio stream is played, the identifier causes the player to access another server to retrieve 
additional information or advertisement to iuvite the user to purchase more content from the 
server (see Abstract of Levy). 

Although Levy mentioned a wired or wireless network. Levy still fails to disclose the 
specific configuration recited in claim 1. Specifically, Levy fails to disclose a network appliance 
to receive a request to play a media object from a controller (e.g., a portable device or PDA) over 
a wireless network (e.g., a first network), to determine whether the requested media object is 
stored ia the network apphance, to retrieve the requested media object from a server over a 
second network different than the first network (e.g., wireless network), and to play the retrieved 
media object within the network appUance (rather than the controller). 

As discussed above, there are at least three parties involved here: a controller, a network 
appliance coupled to the controller over a first network, and a server coupled to the network 
appUance over a second network different than the first network, where the first network is a 
wireless network (also see claim 25 as amended). It is respectfully submitted that Levy fails to 
disclose such configuration. 
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The Office Action contended that col. 4, hnes 20-67; col. 5, lines 1-12; col. 5, line 56 to 
col. 7, line 12; and col. 10, lines 4-29 and 58-67 of Levy disclose the above limitations (see 
1/26/2006 Office Action, page 3). Applicant respectfully disagrees. The cited sections of Levy 
merely described how an audio player downloads audio content firom a server over Intemet and 
plays the downloaded audio content within the audio player. 

Specifically, Levy stated: 

"Once associated with an audio object and metadata, the identifier transforms the 
audio object into a linked object. The identifier remains with the object through 
distribution, although some embedding processes are more robust than others to 
intentional or unintentional distortion/removal of the identifier. There a variety of 
different distribution scenarios. Some examples depicted in FIG. 1 include transferring an 
audio object over a computer network, streaming the object over a computer network, or 
broadcasting it (e.g., AM/FM broadcasting, digital broadcasting, broadcasting over 
wireless carriers, etc.). Whatever the distribution process, a user ultimately receives the 
linked object in a player, tuner, or capture device. 

To activate the linked object, a decoding process extracts the identifier and uses it to 
access associated data or actions. The decoding process may be implemented as a 
separate program or device, or integrated into a player, tuner, or some other capture 
device, such as a listening devices that converts ambient audio waves to an electronic 
signal and then extracts the identifier finom the signal. 

In the configuration shown in FIG. 1, the decoding process forwards the extracted 
identifier to a communication application, which in tum, forwards it in a message to a 
server. The decoding process or the conmiunication ^pUcation may add additional 
context information to the message sent to the to a server. The context information may 
relate to the user, the user's device, the attributes of the session (time of playback, format 
of playback, type of distribution (e.g., broadcast or transmitted audio file), etc) Based on 
identifier and optional context information, the server determines an associated action to 
perform, such as re-directing an identifier or context data to another server, returning 
metadata (including programs, content, etc.), downloading content, logging a transaction 
record. To find the associated action or actions, the server maps the identifier to actions 
based on the information established in the mapping process. The server may: 1) look up 
the data and actions in a local database stored in its memory subsystem; 2) route the 
identifier to one or more other servers via the network, which in tum look up related 
actions and data associated with the identifier; or 3) perform some combination of actions 
1 and 2. 

In the first case, server I returns data or actions associated with the identifier. The 
server may look up related data based on the identifier alone, or based on the identifier 
and other context information. Context information may be information provided by the 
user, by the user's computer or device, or by some other process or device. In the second 
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case, the server looks up one or more addresses associated with the identifier and 
forwards the identifier and/or possibly other context data to secondary servers at these 
addresses via conventional networking protocols. Again, this context data may include 
data from the user, the user's computer, some other device or database. For example, 
server 1 might query a remote database for instructions about how to process an 
identifier- These instruction may specify data to return to the conaminiicatior\ 
application or to forward to another server, which in tiorrv looks tip associated 
data and returns it to the communication application. A server may retxim data 
that an audio player displays to the user or iises to control rendering of the 
content For example, the server can tell the player that the object contains 
inappropriate content for children. The player or user can make decisions about 
whether or how to play the material based on this information." 

(Levy, col. 4, line 20 to col. 5, line 16) 

"In the context of a network configuration, hitemet protocols may be used to 
retum data to the communication apphcation or to the device or system in which it 
operates. The conmiunication application may be implemented in a web browser, such as 
Internet Explorer or Netscape Navigator. Examples of ways of exchanging information 
between a cUent player and a server include returning a web page with metadata and 
program scripts designed to nm on the end user's system. The metadata itself may include 
active links, such as URLs to other network resources, such as a web site or some other 
network service. The path of the identifier fix)m the decoding process, and the retum path 
from a server to the communication apphcation may include one or more hops through a 
wire or wireless connection using standard wire and wireless communication protocols 
Uke TCP/IP, HTTP, XML, WAP, Bluetooth, etc. In addition, data returned to the user 
may be routed through one or more servers that may forward the data, and in some cases, 
augment the data or modify it in some fashion, 

FIG. 2 is a diagram illustrating applications of the system depicted in FIG. I. In 
the application scenarios depicted in FIG. 2, an embedding process encodes an object 
identifier (OID) into an audio file, such as an IDS tag in the header of an MP3 file or 
audio frame headers in the MPS file. FIG. 2 shows two embedding scenarios. The first is 
an MPS distributor that embeds OIDs in MPS files before transmitting them over a 
network, such as the Internet, typically via a web site interface. The second is a file 
ripping process where a programmed computer or other device extracts an audio object 
from packaged media such as a CD and converts it into a coded file format like MPS . Li 
the latter case, the ripping process may extract metadata from the CD, such as the table of 
contents, and use this metadata as a key to a database (CDDB) to get information about 
the songs on the CD, such as title, artists, etc. The table of contents or other metadata 
fipom a package medium, such as optical or magnetic storage or flash memory, may be 
hashed into an index to a database entry that stores information about the media signal 
stored on the medium. The ripping process uses the information returned from the 
database to identify the audio objects on the packaged media so that they can be 
associated with an OID. This is an example of identifying information used to associate 
an ODD with an audio object. As part of the coding process, the ripping process inserts the 
OID in the file header of the MPS file. 
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Later, when a user opens or plays the marked MPS in a player, such as a software player 
like the real player, Liquid Audio player, Windows Media Player (WMP), WinAmp, 
MusicMatctC etc., a plug-in software module in the player extracts the OID and forwards 
it to a server via an Litemet connection. The plug-in may establish its own Intemet 
connection, or pass the OID to an Intemet Browser, which in turn, establishes a 
connection (if one is not already present) with the server. As an intermediate step, the 
plug-in may display a window with user options, such as "learn more about the song", 
"play the song", or both. The user can then choose to get more information by actuating 
the first or third options in the user interface window, which cause the plug-in to forward 
the OK) to the server. 

The server then returns a web page associated with the OID, or re-directs the OID to 
another server (e.g., one maintained by the content distributor or owner), which in turn, 
returns a web page of information about the object and Unks to related actions (e.g., a link 
to a licensing server, a link to a server for buying and downloading related music etc.). 
The licensing server may be programmed to dovraload software players and new music 
offerings compatible with those players. For instance, the licensing server may provide 
software for decrypting, decoding, and playing electronically distributed music according 
to usage rules packaged with the electronically distributed music. In this application 
scenario, the Unking of the MP3 file enables the content owner to market music and 
products that promote the sale of audio objects in other formats, included formats 
protected with encryption, watermark copy managements schemes, etc. 

In the event that a media object is not linked, the decoding and server processes can be 
programmed to enable the user to purchase a link for the object. For example in one 
scenario, the player plug-in displays a graphic for a link information indicating that the 
link is available after determining that an OID is not in the file. If the user clicks on the 
graphic, the plug-in displays more information about the procedure for purchasing or 
renting a link. This information may be provided in conjunction with querying the server 
and displaying information retumed from the server, or alternatively, providing 
preprogrammed information incorporated into the plug-in. If the usct is interested in 
purchasing the link, he or she can then enter input (e.g., click on a button such as "Get 
Link") that initiates the process of registering an ODD with the object and associating 
metadata or actions with the OED. The process of registering the OK) and associating the 
ODD with metadata or actions may be performed as described in this document. This 
scenario provides yet another mechanism for transforming content into cormected 
content" 

(Levy, col. 5, line 51 to col, 7, line 12) 

"While specifically discussed in the context of audio objects, the fingerprinting 
process applies to other types of multimedia content as well, including still images, video, 
graphics models, etc. For still images and video, the identifier can be derived dynamically 
finom a compressed or uncompressed version of the image or video signal. The 
fingerprinting process may be tuned to generate a specific identifier based on the type of 
file format. For example, the process extracts the file format from the file (e.g., from a 
header or footer), then uses a fingerprinting process tailored for that type of file (e.g., a 
hash of a compressed image or video fi:Bme). The dynamic identifier computed by this 
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process may be associated with metadata and/or actions using the processes and systems 
described in this document. 

Registration Process 

One way to implement the registration process is to build client and server application 
programs that communicate over a computer network using standard network 
communication protocols , The client may be implemented as a software program that 
provides identifying information about an audio object It can obtain the information by 
prompting the user for the identifying information, or from extracting it from the audio 
object or its container. The server maybe implemented as a database management 
program that manages identifiers and corresponding audio objects. When queried to 
provide an identifier for particular identifying information, the program checks whether it 
has already assigned an identifier to an object based on the identifying information. If so, 
it returns that identifier that has already been assigned. If not, it assigns a new identifier 
number, creates a new entry in the database for that number and its associated identifying 
information. 

One example is a broadcaster ID, such as a radio station ID. Audio broadcast by, 
the radio station is embedded with this radio station ID. To identify the object, context 
information such as the play time captured at the tuner is used along with the radio station 
ID extracted from the received audio signal to identify the audio object. The decoding 
process forwards this information to a server. Using the radio station ED and context 
information, the server maps the ID to an appropriate action. This may include querying a 
radio station's playlist database for an object identifier based on the station ID and 
context information. The server can then map the object identifier to an action or 
metadata based on the object ID returned from the playlist database. Other scenarios are 
possible. For example, the server could forward the station ID, context data and decoder 
address to a radio station server, which in turn, looks up the appropriate action or 
metadata (e.g., web page) and sends it to the device that decoded the station ID." 

(Levy, col. 10, lines 4-35 and 50-67) 

Thus, the cited sections of Levy are related to how to use the identifier to access 

additional context information and perform further action and how to embed an identifier within 

an audio stream. There is no disclosure v^dthin Levy of a specific configuration recited in claim 1 

(e.g., a three-party configuration set forth above), where a controller instructs a network 

apphance over a wireless network to retrieve a media object from a server over a second netwoik 

different than the wireless network if the requested media object is not stored in the network 

appliance, and the network appliance plays the requested media object. 
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Even ifi for the sake of argument, the audio player (e.g., MPS player) of Levy may be 
considered as a network appliance as recited in claim 1, such an audio player does not receive a 
request to play a media object from a controller over a wireless network (e.g., a first network), 
download the requested media object from a server over a second network different than the first 
network(e.g., wireless network), and play the media object for the controller. There is no 
mention of a controller wirelessly communicating with an appliance within Levy. 

In contrast, according to certain embodiments of the present application, the media object 
is not stored within the controller and the controller only stores identifiers for identifying the 
media objects. In response to the identifier wirelessly received from the controller, the network 
apphance detennines whether the identified media object is stored within the network apphance. 
If so, the network appliance will play the media object. Otherwise, the network appliance 
downloads the media object from server over another network (e.g., Intemet) and plays the 
downloaded media object. 

Dom is related to a GUI for selectively download and displaying video data objects while 
Morris is related to a GUI for manipulating a collection of digital media. It is respectfully 
submitted that Dom and Morris also fail to disclose or suggest the limitations set forth above 
with respect to claim 1. 

In addition, both Dom and Morris are related to GUIs for manipulating digital objects, 
while Levy is related to embedding an identifier within an audio stream for the commercial 
advertisement pinposes. There is not suggestion within Levy, Dom, and Morris to combine with 
each other. Levy, Dom, and Morris are solving significantly different problems and their 
approaches are significantly different. One with ordinary skill in the art would not combine 
these references because such a combination lacks motives and reasonable expectation of 
success. Such a combination can only be found based on the impermissible hindsight of 
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Applicant's own disclosure. Even if Levy, Dom, and Morris were combined, such a combination 
still lacks the limitations set forth above. 

In order to render a claim obvious, each and every limitations of the claim must be taught 
by the cited references, individually or in combination. It is respectfully submitted that Levy, 
Dom, and Morris, individually or in combination, fail to disclose the limitations set forth above. 
Therefore, for the reasons set forth above, it is respectfiilly submitted that claim 1 as amended is 
patentable over the cited references. 

Similarly, independent claims 29 and 44 include limitations similar to those recited in 
claim L Thus, for the reasons similar to those discussed above, independent claims 29 and 44 
are patentable over the cited references. 

Given that the rest of the claims depend from one of the above independent claims, at 
least for the reasons similar to those discussed above, it is respectfully submitted that the rest of 
the claims are patentable over the cited references. Withdrawal of the rejections is respectfully 
requested. 

In view of the foregoing. Applicant respectfully submits the present application is now in 
condition for allowance. If the Examiner believes a telephone conference would expedite or 
assist in the allowance of the present application, the Examiner is invited to call the undersigned 
attomey at (408) 720-8300. 
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Please charge Deposit Account No, 02-2666 for any shortage of fees in connection with 



this response. 



Respectfully submitted, 



BLAKELY, SOKOLOFF, TAYLOR & ZAFMAN 



Kevin G. Shao 
Attorney for Applicant 
Reg. No. 45,095 
Kevin_Shao@bstzxom 

12400 Wilshire Boulevard 
Seventh Floor 

Los Angeles, Cahfomia 90025-1026 
(408) 720-8300 



Date: 
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